home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1996 April: Mac OS SDK / Dev.CD Apr 96 SDK / Dev.CD Apr 96 SDK1.toast / Development Kits (Disc 1) / OpenDoc / Sample Code / Sample Editors⁄Viewers / Draw Editor / DrawEditor Read Me < prev    next >
Encoding:
Text File  |  1995-12-15  |  4.8 KB  |  54 lines  |  [TEXT/ttxt]

  1. DrawEditor
  2. By The OpenDoc™ Sample Code Team
  3. December 15, 1995
  4.  
  5.  
  6. © 1993-1995  Apple Computer, Inc. All Rights Reserved.
  7. Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
  8. Mac and OpenDoc are trademarks of Apple Computer, Inc.
  9. ----------------------------------------------------------------------------------------------------------------------------
  10.  
  11.  
  12. DrawEditor is the largest and most fully functional of the sample parts. Interestingly enough, it also has the most bugs.  This isn't to say that DrawEditor is not a good sample of a container part, it's just that you need to be wary if you plan to derive your work from it.  
  13.  
  14. DrawEditor needed to be designed and implemented in a fairly short period of time ( for a part of its size ). In order to save time, I began using SamplePart C++ as a seed for DrawEditor. In order to take advantage of SamplePart bug fixes I intentionally kept much of DrawEditor's base implementation the same as SamplePart's. So, you will notice many methods which are identical to SamplePart. 
  15.  
  16. Container parts tend to be very large and as such need to be factored as well as possible. DrawEditor started out pretty well factored and wound up a little worse for the wear as a result of latent changes in OpenDoc.
  17.  
  18. That said, here are some notes:
  19.  
  20. Things that should have been done
  21.  
  22. • I should have thought more about linking during the initial design process.  The structure of the objects representing content should have been slightly different to better incorporate linking.  Basically we feel that ( in a Draw type content model at least ) that there should be a content object to represent links. This is discussed further in the “Linking Notes” document located in this folder.
  23.  
  24. • I tried to move most of the code into the content objects.  You'll notice functions in the shape classes that handle notifications which are passed to the part. Like, DisplayFrameClosed and DisplayFrameRemoved, for example. These two methods are implemented in the C++ class DrawEditor as well as the Shape class hierarchy.  In this case the DrawEditor method DisplayFrameClosed iterates over its shapes and calls DisplayFrameClosed on each of them. This way, any embedded shapes can remove their embedded frames from the display frame going away. There are a number of such notifications in shape which emulate OpenDoc notifications. I wasn't able to completely hide the content implementation in the shape classes, there are some things that need knowledge global to shapes. Towards the end I added the CDrawContent class to the part to handle the various types of interchange required by OpenDoc. I think that some of the content related code in DrawEditor that couldn't go into shape could be moved into CDrawContent.
  25.  
  26. • Insert, Bundled Frames, multiple kind support, should have been implemented and were not.
  27.  
  28. Known Bugs
  29.  
  30. • With DrawEditor as the root, embed another DrawEditor within it. Embed another DrawEditor within it ( as a sibling to the other ). Drag one into the other, undo drag. Close: you will get a ref counting error in the debug build. This has to do with the fact that the frame that is cloned in the drag is in "limbo" and isn't released correctly. You can read more about "limbo" in the OpenDoc documentation.
  31.  
  32. • When parts derived from the OpenDoc sample code are embedded inside DrawEditor, all parts are redrawn whenever an embedded part is activated. This does not happen when, say, ODF parts are embedded inside OpenDoc. I suspect it may have something to do with the fact that the sample code parts aren't using the invalidshape when focusing to draw.
  33.  
  34. • If you open DrawEditor, then show the palettes, then embed something, then open the embedded thing into a window then close the embedded thing's window, DrawEditor's palettes will hide.
  35.  
  36. • When DrawEditor is embedded inside of a part that can print, not all of DrawEditor's content is printed.
  37.  
  38. • DrawEditor does not display a hand cursor when the user moves the mouse over the active border of an embedded part. The HI says to do this. In addition, the cursor should change when the mouse is over a selected object's resize handles.
  39.  
  40. • Growing DrawEditor's display window will not always cause the grid to be redrawn.
  41.  
  42. • Sometimes when opening DrawEditor from stationery ( as opposed to a document ) embedded part handles are drawn in green. They should be black.
  43.  
  44. • The polygon tool in DrawEditor doesn't work. There is no code there. 
  45.  
  46. • The triangle tool works, but does not draw the triangle as soon as it is dragged out. It waits for the next update event. 
  47.  
  48. • According to the OpenDoc HI there should be a menu item: "Show Frame Outline…".  DrawEditor does not yet implement this feature.
  49.  
  50. • DrawEditor does not display link borders, either.
  51.  
  52. There are probably more I don't know about. Sorry. Good luck with your container parts.
  53.  
  54.